1. Field of the Invention
The invention relates to a development device and a method for creating and testing a control unit program. The control unit program here is designed to control an electronic control unit in a vehicle.
2. Description of the Background Art
Development devices and methods for creating and testing control unit programs of the aforementioned type are known from the prior art. Generally, they serve the user as a development tool for creating, developing, testing, simulating, and/or calibrating control unit programs, for example for a real electronic control unit, or else a virtual electronic control unit (V-ECU) and/or a virtual processing unit (VPU).
A V-ECU is a virtual control device, which is to say a control unit program that has no direct hardware connection but that reflects all specific characteristics of the hardware. The V-ECU is integrated into a simulator in order to simulate the behavior of a real control device. V-ECUs can be used within the framework of an offline or real-time simulation. V-ECUs utilize interfaces of the simulator backplane in order to communicate with other control devices, models of the controlled system, or I/O drivers. In the user's perception, the V-ECU often stands in for his entire ECU, including all driver modules. In the technical sense, however, the V-ECU only comprises the parts of the program above the backplane interface, since the lower program levels are replaced by backplane modules of the specific simulator. At run time, the V-ECU is embedded in a frame (VPU) with the aid of a VPU integration code in order to make it into an executable simulator process. Within the scope of the present patent application, such an executable simulator process is described as an executable program. This executable program can be composed of one or more control unit program components and/or test scenario program components. The program components, in turn, can perform one or more different functions. Regardless of the number of integrated program components, just one runtime environment is generated. This permits testing of device program components in an existing program architecture. To this end, all that is required is for the particular program architecture to be expanded by test components and the runtime environment to be configured and regenerated.
A VPU is a virtual processing unit within the simulator on which an application that is to be simulated is executed. A VPU has its own allocated virtual computing resources (core), virtual memory (RAM), and virtual timer. These resources are independent of other VPUs, so the VPUs are simulated more or less in parallel. Likewise, the VPU has a separate set of OS resources (tasks, counters, alarms, events, critical sections, etc.). The utilization of I/O drivers and communication with other VPUs takes place through backplane services. In a real-time system, VPUs are generally executed on a separate physical core. In an offline simulation, the allocation of VPUs to cores is carried out dynamically by the underlying operating system of the simulation environment (Windows, for example).
An exemplary development device of the aforementioned type can be found in the product description of SystemDesk 3.1: (http://www.dspace.de/de/gmb/home/products/sw/system_architecture_software/system desk.cfm). SystemDesk is a tool for supporting the development of distributed electronic systems. SystemDesk is especially designed to create control unit programs that can be used within the framework of the standard known as the AUTOSAR (Automotive Open System Architecture) standard.
The known prior art development devices generally provide a user with a user interface for the development device, by which means a model or an architecture of the control unit program can be reproduced graphically, for example in the form of a tree structure with multiple program components, and can be processed. As the complexity of modern control unit programs and their models or architectures grows, so too does the complexity of the development devices to be used for producing such control unit programs. Early testing of individual program components has thus become an essential element of modern program development within the framework of complex program structures so as to be able to identify, at an earlier point in the development process, possible sources of error in the later process sequence. A method for model-based design that does not consider testing and validation steps as a final step in the process, but rather as a continuous, accompanying activity, is described in the publication by Sandmann, G. and Thompson, R., “Development of AUTOSAR Software Components within Model-Based Design,” SAE Technical Paper 2008-01-0383, 2008. In addition to test scenarios such as are developed by design and test engineers, the method also provides means for automatically generating test cases such as are defined, for example, for MC/DC (modified condition/decision coverage) in the D0-178B Standard for Level A Software.
However, in addition to application-specific test scenarios, it is necessary to test that the individual applications function correctly with regard to possible errors that could occur in the process chain of data to be processed—such as, e.g., delay or failure of the internal signal transmission from one electronic control element to another. Previous implementations of test environments based on the AUTOSAR standard that consist of an application program component that is connected to a test scenario program component through a runtime environment already permit integrated tests of multiple electronic control units acting in conjunction with one another that are each considered as a separate black box, such as is described in “Testautomatisierung für Steuergeräte-Programme mit AUTOSAR Architektur” [test automation for control unit programs with AUTOSAR architecture] (http://www.fkfs.de/fileadmin/media/04_unternehmen/veranstaltungen/autotest/pdf dokumente/paper—2008/paper—11_SYSTECS_Zurawka.pdf), and all input and output signals of the control units are available for manipulations in a global data pool. Consequently, early testing in integrated form is already possible even for different states of development. The actual automatically generated AUTOSAR runtime environment is simulated by mechanisms of the test system.
Another test system is described in the publication, “Messina 2.9 von Berner & Mattner: Neues Release verbessert AUTOSAR-Unterstützung für modellbasiertes Testen” [Messina 2.9 from Berner & Mattner: new release improves AUTOSAR support for model-based testing], published in January 2011. Here, the Messina program creates a separate test runtime environment for each integrated program component of an integrated test on the basis of the AUTOSAR XML file. Communication of the individual test runtime environments is simulated by the means that a virtual function bus models the communication of the runtime environment interfaces, such as transmitter/receiver ports or client/server ports. In this way, imitation or testing of client/server operations is permitted. The applicable test runtime environments thus serve to connect the individual program component to the Messina platform.